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(57) A number of methods and apparatus are dis- 
closed for providing transparent persistence in a distrib- 
uted object operating environment are disclosed. In 
general, the present invention teaches replacing the val- 
ue in the object's data pointer (addressing information 
which points to the objects limited persistent memory) 
with a pointer value which points out to another persist- 
ent storage device. In preferred embodiments, a persist- 



ent storage manager (external and transparent to the 
distributed object) maintains the object data. In a spe- 
cific embodiment, a distributed object framework is pro- 
vided which has the mechanism for providing the trans- 
parent persistent strategy of the present invention. An 
object developer develops object implementations 
which the distributed object generates distributed ob- 
jects with, in the process automatically providing trans- 
parent persistence. 
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Description 

BACKGROUND OF THE INVENTION 

The present invention relates to the fields of distrib- 
uted computing systems, client-server computing and 
object-oriented programming. More specifically, the 
present invention teaches methods and apparatus for 
providing transparent persistence within a distributed 
object operating environment. 

Object oriented programming methodologies have 
received increasing attention over the past several 
years in response to the growing tendency for software 
developed using traditional programming methods to be 
delivered late and over budget. This stems from the fact 
that traditional programming techniques that emphasize 
procedural models and "linear" code tend to be difficult 
to design and maintain in many circumstances. Gener- 
ally, large programs created using traditional methods 
are "brittle". That is, even small changes can effect nu- 
merous elements of the prog ramming code. Thus, minor 
changes made to the software in response to user de- 
mands can require major redesign and rewriting of the 
entire program. 

Object oriented programming strategies tend to 
avoid these problems because object methodologies fo- 
cus on manipulating data rather than procedures; thus 
providing the programmer with a more intuitive ap- 
proach to modeling real world problems. In addition ob- 
jects encapsulate related data and procedures so as to 
hide that information from the remainder of the program 
by allowing access to the data and procedures only 
through the object's interface. Hence changes to the da- 
ta and or procedures of the object are relatively isolated 
from the remainder of the program. This provides code 
that is more easily maintained as compared to code writ- 
ten using traditional methods, as changes to an object's 
code do not affect the code in the other objects. In ad- 
dition, the inherent modular nature of objects allows in- 
dividual objects and interfaces to be reused in different 
programs. Thus, programmers can develop libraries of 
"tried and true" objects and interfaces that can be used 
over and over again in different applications. This in- 
creases software reliability while decreasing develop- 
ment time, as reliable programming code may be used 
repeatedly. 

A more recent advance in the field of object oriented 
methodologies has been the implementation of distrib- 
uted object operating environments over computers in- 
terconnected via a computer network. As used herein, 
the term, "distributed object" or "object" refers to an en- 
capsulated package of code and data that can be ma- 
nipulated by operations through an interface. Thus, dis- 
tributed objects will be seen by those skilled in the art 
of object oriented programming (OOP) as including the 
basic properties that define traditional programming ob- 
jects. However, distributed objects differ from traditional 
programming objects by the inclusion of two important 



features. First, distributed objects are multilingual. That 
is, the interfaces of distributed objects are defined using 
an interface definition language that can be mapped to 
a variety of different programming languages. One such 

5 interface definition language is Object Management 
Group's IDL. Second, distributed objects are location- 
independent, i.e., distributed objects can be located an- 
ywhere in a network. This contrasts sharply with tradi- 
tional programming objects which typically exist in a sin- 

10 gle address space. 

Elaborating further on the distributed object operat- 
ing environment, distributed objects can be object cli- 
ents or object servers, depending upon whether they are 
sending requests to other objects or replying to requests 

'5 from clients. In a distributed object operating environ- 
ment, requests and replies are made through an Object 
Request Broker (ORB) that is aware of the locations and 
status of the objects. One architecture which is suitable 
for implementing such an ORB is provided by the Com- 

20 mon Object Request Broker Architecture (CORBA) 
specification. The CORBA specification was developed 
by the Object Management Group (OMG) to define the 
distributed computing environment world in terms of ob- 
jects in a distributed client-server environment, where 

25 server objects are capable of providing services to cli- 
ents requesting the service. 

When a client calls a target object, certain proce- 
dures must be performed to ensure that the target object 
can perform the requested service. These procedures 

30 include identifying and locating the target object, starting 
the server process (if necessary) under which the target 
object resides, activating the target object (if neces- 
sary), and, finally, establishing a connection with the tar- 
get object and passing the call. The ORB together with 

35 an Object Adapter (OA) is responsible for working with 
the client and the target object to perform these servic- 
es. 

From the perspective of the distributed object life 
cycle, objects fall into one of two categories: transient 

40 or persistent. When discussing the transient or persist- 
ent nature of an object, what is being referred to is the 
transient or persistent nature of the object's state. As 
will be well familiar to those skilled in the art of object 
oriented programming (OOP), an object may be de- 

45 scribed by two components: executable code and state. 
Executable code is essentially the instructions by which 
the object operates; it defines the "behavior" of the ob- 
ject. State is simply the remaining portion of the object 
such as data which is not code. 

50 The majority of prior art teaching is directed towards 
transient objects. Transient objects typically have a 
short life span and are bound to a single host computer 
process. That is, when a host computer process ceases, 
all transient objects residing in the host computer proc- 

55 ess cease. Therefore there is no continuity of identity of 
a transient object from one process to another. Because 
transient objects are bound to a single process, they in- 
herently cannot change their location. Hence transient 
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objects could also be referred to as "immobile" objects, 
as their addresses may never change. A programmer 
whose object kinds include only transient objects is lim- 
ited in preserving the object state from instance to in- 
stance. 

In contrast, persistent objects are not bound to a 
single process and their address and memory location 
may change over time (e.g., they may have many "life" 
cycles). With a persistent object, there is a continuity of 
identity from one process to another. In brief, persistent 
objects are objects whose state can outlive the life of a 
specific instance of the object. As will be appreciated, 
persistent objects may provide many advantages to the 
object developer. Unfortunately, prior strategies for im- 
plementing persistent objects fall short of providing a 
satisfactory solution to the object developer, as will be 
described below. 

In what is perhaps the crudest strategy for providing 
persistent objects, the programmer codes within the ob- 
ject the reading and writing (i.e., the management) of 
data from a permanent storage medium such as a hard 
disk drive. While this strategy may work for simple sce- 
narios, there are at least two glaring defects. First, the 
object developer bears the burden for implementing this 
data management into each persistent object. Second, 
this strategy has an abundance of unnecessary over- 
head. By way of example, each object must include the 
previously mentioned code for persistent data support. 
Furthermore, the structure of the data file may become 
quite intricate, demanding elaborate parsing just to read 
and write data. All of this data management must be 
done at execution time by the object, resulting in an ex- 
pensive solution in terms of system resource utilization. 
Additionally, given the complexities of a distributed ob- 
ject operating environment, it would be extremely diffi- 
cult for an object developer to implement their own per- 
sistent strategy. This is due, in part, to the nature of dis- 
tributed objects which could have many surrogate ob- 
jects located through out the system. 

In another approach for providing persistent ob- 
jects, persistence has been introduced into existing ob- 
ject programming languages. In one approach, an ex- 
tension to the existing programming language provides 
an interface to the functionality of a database. For ex- 
ample, a compiler for an extended language using this 
approach might accept a specialized set of commands 
geared for use with a database. The most common type 
of database used with these methods is a relational da- 
tabase. As relational databases were not designed for 
storing data in a format in which object state is typically 
found, this may introduce its own set of dilemmas. Ob- 
ject oriented databases are available, but objects creat- 
ed by object oriented databases are not CORBA objects 
and so cannot take advantage of the CORBA guide- 
lines. Inany event, each of the prior art strategies places 
an undue burden on the programmer as they must still 
consciously manage the object data persistence. 

Turning now to Fig. 1 , a specific object designed ac- 



cording to the CORBA specification will be discussed. 
Fig. 1 shows a servant object 1 20 of a distributed object 
class including transient data 122, a data object pointer 
124, and a data object 128. By way of background, a 
s class is a template from which objects can be created. 
The class specifies the behavior and attributes common 
to all instances of the class. As will be appreciated by 
those skilled in the art of object oriented programming, 
when a new instance of a class is created, the memory 
10 for the instance variables is allocated. The servant ob- 
ject 120 is one instance of a distributed object. Fig. 1 
diagramatically illustrates the memory allocation of 
servant object 1 20. Note that this memory is contiguous. 
Transient data 1 22 is the memory portion of the servant 
is object 120 which contains state (e.g., variables) which 
the object needs to use only as transient data. 

By way of analogy, the transient data may be envi- 
sioned as a scratch pad area for use only by this in- 
stance of the servant object 120. Data object 128 is the 
memory portion of the instance which the object intends 
for use as persistent state. Initially when the servant ob- 
ject 1 20 is created, an object constructor will create the 
servant object 120 with transient data 122 and data ob- 
ject 128 initially empty. Both the initialization function 
(executed during creation) and the activation function 
(executed during activation) must perform any required 
initialization. As discussed previously, the object devel- 
oper must incorporate some type of persistence strate- 
gy in order to maintain and call up the data object 128 
so that the data is maintained through creation and the 
activation/deactivation cycles. One common method is 
to write elaborate initialization functions and activation 
functions which perform these tasks. 

The CORBA specification does provide one possi- 
ble hook for helping the object developer to manage per- 
sistent data. In an object adapter database (OAD), the 
ORB maintains, for each registered object, up to {kilo- 
byte (Kbyte) of persistent portion of data that is termed 
the reference data. Upon activation, the object obtains 
a reference key which serves as a key for locating the 
appropriate reference data within the OAD. The devel- 
oper can utilize the 1 Kbyte reference data to store the 
persistent data associated with data object 128, but the 
IKbyte constraint may be unsuitable for many applica- 
tions. Thus the object developer must implement a more 
elaborate persistence strategy. For example, a list of 
pointers directing the object to memory space contain- 
ing the persistent data may work. Nevertheless within 
the CORBA specification, the burden of implementing a 
persistence strategy still rests on the object developer. 

What is needed is a method and apparatus which 
will implement persistent data storage for traditional pro- 
gramming objects and distributed objects in such a way 
that the persistence mechanism is transparent to the ob- 
ject developer. That is, the persistence mechanism will 
be transparent persistence. As will be appreciated, 
transparent persistent objects may make the life of the 
object oriented programmer easier as the programmer 
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will not have to implement the explicit loading and saving 
of state. Thus, what is needed is a method and appara- 
tus for providing transparent persistent object support. 

SUMMARY OF THE INVENTION 

The present invention addresses the above-de- 
scribed limitations by providing methods and apparatus 
for providing persistent data support for objects in a dis- 
tributed object operating environment. In particular, the 
methods and apparatus described herein relieve the ob- 
ject programmer from many of the burdens associated 
with the creation of persistence in objects by providing 
support for such persistence relatively transparently to 
the programmer. 

In one aspect, the present invention includes a com- 
puter-implemented method for providing a distributed 
object having transparent persistent data support for 
use on a distributed object system. The method of the 
invention includes providing a servant object having an 
associated data object in which transient data can be 
stored and a data object pointer that indirects to the as- 
sociated data object. The servant object inherits the da- 
ta object from a data object class. The method also in- 
cludes providing a persistent data storage mechanism 
having a persistent data object in which persistent data 
is stored, and a persistent data pointer that indirects to 
the persistent data object. Further, the value of the data 
object pointer is determined; and the data object pointer 
is located within the servant object and replaced with 
the persistent data pointer to produce thereby a distrib- 
uted object having transparent persistent data support. 

In a second aspect, the present invention provides 
a computer system for creating a distributed object hav- 
ing transparent persistent data support. The computer 
system of the invention includes a data compiler to com- 
pile data schema into a data object class and an imple- 
mentation compiler to compile implementation files into 
compiled implementations. In addition, the computer 
system includes a final stage compiler to create a serv- 
ant object constructor capable of creating a servant ob- 
ject, the servant object including a transient data space, 
a data object pointer and a data object, wherein the serv- 
ant object inherits the data object pointer from the data 
object class. Further included is a persistent data stor- 
age mechanism that includes a persistent database, 
and a persistent data object that is an image of the per- 
sistent database. Finally the computer system includes 
a transparent persistence mechanism that includes a lo- 
cator to find the value of the data object and the address 
space of the data object, and a replacement mechanism 
to swap the value of the data object in the address space 
with a pointer to the persistent data object. 

In yet another aspect, the present invention in- 
cludes a distributed object suitable for use on a distrib- 
uted object system. The distributed object includes a 
transient data space for storing transient data, a data 
object and a persistent data pointer that indirects the 



reading and writing of persistent data from the data ob- 
ject to a persistent data object that is an image of a per- 
sistent database. 

s BRIEF DESCRIPTION OF THE DRAWINGS 

The invention, together with further objects and ad- 
vantages thereof, may best be understood by reference 
to the following description taken in conjunction with the 
io accompanying drawings which are described below. 

FIGURE 1 is a diagrammatic illustration of the mem- 
ory allocation of the instance variables of a servant ob- 
ject of the prior art. 

FIGURE 2 is a diagrammatic illustration of one par- 
is adigm for the compilation of the object constructor, the 
object constructor being used to create an instance of 
an object in accordance with one embodiment of the 
present invention. 

FIG URE 3 is a diagrammatic illustration of the mem- 
20 ory allocation of the instance variables of a servant ob- 
ject in accordance with one embodiment of the present 
invention, the figure also shows a persistent data object 
which is a replica of a data object portion of the servant 
object which is mapped from a persistent database into 
25 transient memory both during creation and activation. 

FIGURE 4 is a pictorial illustration of a process in 
accordance with one embodiment of the present inven- 
tion, wherein the process has multiple threads of exe- 
cution, file identifiers, memory allocation, and an object 
30 resident therein. 

FIGURE 5 is a pictorial illustration of various com- 
puters linked together in a computer network. 

FIGURE 6 illustrates diagramatically the major 
components of a computer in Figure 5. 
55 FIGURE 7 is a flow chart illustrating a method for 
creating an instance of a distributed object utilizing 
transparent persistence in accordance with one method 
aspect of the present invention. 

FIGURE 8 is a flow chart illustrating a more detailed 
40 description of one embodiment of step 212 of FIGURE 
7. 

FIGURE 9 is a flow chart illustrating a method for 
activating an object utilizing transparent persistence in 
accordance with one method aspect of the present in- 
45 vent ion. 

FIGURE 10 is a flow chart illustrating a method of 
deleting an object utilizing transparent persistence in ac- 
cordance with one method aspect of the present inven- 
tion. 

so 

DETAILED DESCRIPTION OF THE INVENTION 

The present invention relates to a distributed oper- 
ating environment based on object oriented program- 
55 ming (OOP). More specifically, this invention discloses 
methods and apparatus for providing transparent per- 
sistence in a distributed object operating environment. 
Following the Definition of Terms, the methods and ap- 
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paratus will be discussed in more detail, first through 
describing several embodiment of the apparatus of the 
present invention, next discussing example computer 
processes, networks, and computer systems which are 
suitable for the present invention, subsequently contin- 
uing with a detailed description of several further em- 
bodiments of the apparatus and data structures of the 
present invention, and then further through the detailed 
description of the method aspects of the present inven- 
tion. 

I. DEFINITION OF TERMS 

As used herein, the term "distributed object" or "ob- 
ject" refers to an encapsulated package of code and da- 
ta that can be manipulated by operations through a de- 
fined interface that is associated with an object. Thus, 
distributed objects will be seen by those skilled in the 
art as including the basic properties that define tradition- 
al programming objects. However, distributed objects 
differ from traditional programming objects by the inclu- 
sion of two important features. First, distributed objects 
are multilingual. The interfaces of distributed objects are 
defined using an interface definition language that can 
be mapped to a variety of different programming lan- 
guages. One such interface definition language is 
OMG's IDL. Second, distributed objects are location-in- 
dependent, i.e., distributed objects can be located any- 
where in a network. This contrasts sharply with tradition- 
al programming objects which typically exist in the same 
address space as the client. Distributed objects can be 
object clients or object servers, depending upon wheth- 
er they are sending requests to other objects or replying 
to requests from other objects. Requests and replies are 
made through an Object Request Broker (ORB) that is 
aware of the locations and status of the objects. 

A "distributed object system" or "distributed object 
operating environment" refers to a system comprising 
distributed objects that communicate through an ORB. 

An "object reference" or "objref is an object that 
contains a pointer to another object. Additionally, an ob- 
jref can include a portion of memory (the "sub-object 
identifier") which can be used for identifying a sub-ob- 
ject. With the exception of the sub-object identifier, the 
creation and definition of object references will be famil- 
iar to those skilled in the art. A "client" as defined herein 
refers to an entity that sends a request to second object. 
In this model, the second object is referred to as a "serv- 
er object" or a "target object". Thus, clients invoke op- 
erations, or implementations, from servers. In a distrib- 
uted object environment, clients need not have knowl- 
edge of the implementation programming language, nor 
does the implementation have to have knowledge of the 
client's programming language due to the requirement 
of multilingual character of such objects. Clients and 
servers in distributed object environments need only 
communicate in terms of the interface definition lan- 
guage. As noted above, the request by the client to the 



server, and the server's reply to the client, is handled by 
the ORB. It should be pointed out that the client and 
server can exist within the same process, on the same 
host computer, or on two different host computers. 

5 An "object interface" is a specification of the oper- 
ations, attributes, and exceptions that an object pro- 
vides. Preferably, object interfaces for distributed ob- 
jects are written using an IDL. As noted above, objects 
perform transactions through their interfaces. The use 

io of interfaces therefore relieves the need of objects that 
are aware of the programming languages used to define 
the methods and data of the objects in the transaction. 

To "marshal" a packet of information is to prepare 
this information for transfer both over a network com- 

15 munications line or via shared memory. This often 
means organizing the data in a particular format in ac- 
cordance with the network communications protocol be- 
ing used. 

To B un marshal 0 a packet of information is to essen- 
20 tially reverse the marshaling procedure and produce da- 
ta in a format which is meaningful in a non-network en- 
vironment. 

As used herein, the phrase "transparent persist- 
ence" is the mechanism by which persistent data stor- 
es age and management is transparently provided to an 
object developer. 

II. TRANSPARENT PERSISTENCE 

30 According to the present invention, a variety of 
methods and apparatus for providing transparent per- 
sistence to a programming object in a distributed object 
operating environment are disclosed. As used herein, 
the phrase "transparent persistence" is the mechanism 

35 by which persistent data storage and management is 
transparently provided to an object developer. In some 
embodiments, the present invention teaches transpar- 
ently configuring the object's instance variable structure 
(especially the addressing information which points to 

40 the object's limited persistent memory) and automatical- 
ly managing the object's related persistent data. In some 
embodiments, a persistent storage manager (external 
and transparent to the distributed object) maintains the 
persistent object data. 

45 In one embodiment described herein, the transpar- 
ent persistent strategy takes advantage of the nature of 
the object compilation and the principle of inheritance 
as follows. When an object developer declares data var- 
iables in their data schema it is done by way of a direct 

50 relationship. However, when the object developer's data 
schema is compiled into data object classes, the direct 
relationship is converted by the compiler into an indirec- 
tion. (An "indirection" is a set of information, a pointer, 
etc., which directs the client entity to a source, e.g., a 

55 locator object, which can direct the client entity to the 
object. By way of analogy, if a client requested geo- 
graphical directions, an indirection would point the client 
to the location of a current map, or perhaps provide the 
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client with a phone number of a geographically astute 
individual.) 

Thus, the direct relationship is converted so that up- 
on object activation the relationship will instead be a da- 
ta pointer that is inserted by the compiler and about 
which the object developer is unaware. The data pointer 
will indirect to a data object located in memory contigu- 
ous to the other instance variables. When the object is 
activated, thereby generating a single instance of the 
object class, the instance inherits behavior and at- 
tributes of the object class including the data pointer to 
the data object. The present invention teaches, upon ob- 
ject activation, creating a replica of a persistent data ob- 
ject and replacing the initial data pointer to the data ob- 
ject with a pointer to the persistent data object 

Objects can be object clients or object servers, de- 
pending upon whether they are sending requests to oth- 
er objects or replying to requests from clients. In a dis- 
tributed object environment, requests and replies are 
made through an Object Request Broker (ORB) that is 
aware of the locations and status of the objects. One 
architecture which is suitable for implementing such an 
ORB is provided by the Common Object Request Broker 
Architecture (CORBA) specification. The CORBA spec- 
ification was developed by the Object Management 
Group (OMG) to define the distributed computing envi- 
ronment world in terms of objects in a distributed client- 
server environment, where server objects are capable 
of providing services to clients requesting the service. 
In the following discussion, the terms "object" and "dis- 
tributed object" will often be used interchangeably. How- 
ever, in general, distributed objects have the quality of 
being accessible (via the ORB) to clients throughout a 
distributed object operating environment, whereas non- 
distributed objects, such as C++ or SmallTalk object, are 
only available to clients resident in the same process as 
the common object. Those skilled in the art will be able 
to differentiate between the two either from the context 
or by an explicit identifying statement. 

When a client calls an object, it must have address- 
ing information corresponding to the object. In a non- 
distributed object oriented operating environment, cli- 
ents can only interact with objects which are resident in 
the same address space, that is, within the same proc- 
ess. Thus the addressing information is typically just a 
pointer directing to the address space where the target 
object resides. 

In a distributed object operating environment, how- 
ever, the client must have an object reference for the 
desired target object (if it is a remote object). The object 
reference essentially contains sufficient addressing in- 
formation to direct the client to the target object. The 
object reference addressing information may be direct 
addressing information. For example, the direct ad- 
dressing information may include a host computer net- 
work address, a server process network port number, 
and a target object identifier. However, the addressing 
information may be an indirection or a combination of 



direct addressing information and an indirection. 

For a more detailed description of addressing infor- 
mation, as well as suitable embodiments of different 
kinds of object references, please see Brownell et. al.'s 
s copending United States Patent Application Serial No. 
(Attorney Docket No. SUN1P025/P721) entitled 
"METHODS, APPARATUS, AND DATA STRUCTURES 
FOR MANAGING OBJECTS", which is incorporated 
herein by reference in its entirety. Furthermore, one suit- 

10 able embodiment for establishing and terminating con- 
nections between objects in a distributed object operat- 
ing environment is disclosed in Brownell et. al.'s co- 
pending United States Patent Application Serial No. (At- 
torney Docket No. SUN1 P01 8/P71 5) entitled 'METHOD 

is AND APPARATUS FOR MANAGING CONNECTIONS 
FOR COMMUNICATION AMONG OBJECTS IN A DIS- 
TRIBUTED OBJECT SYSTEM" which is incorporated 
herein by reference. 

When a client calls a target object, certain proce- 

20 dures must be performed to ensure that the target object 
can perform the requested service(s). These proce- 
dures include identifying and locating the target object, 
starting the server process (if necessary) under which 
the target object resides, activating the target object if 

25 necessary, coordinating the target object's persistent 
state with its implementation (if necessary), and, finally, 
establishing a connection with the target object and 
passing the call. The ORB together with an Object 
Adapter (OA) is responsible for working with the client 

30 and the target object to perform these services. 

In preferred embodiments of the present invention, 
the transparent persistence mechanisms of the present 
invention are implemented automatically by an object 
development framework which the object developer us- 

35 es to develop distributed objects. One such framework 
is described in more detail in Snyder et. al.'s copending 
United States Patent Application Serial No. (Attorney 
Docket No. SUN1P022/P719) entitled "METHOD AND 
APPARATUS FOR GENERATION AND INSTALLA- 

40 TION OF DISTRIBUTED OBJECTS ON A DISTRIBUT- 
ED OBJECT SYSTEM" which is incorporated herein by 
reference in its entirety. One suitable object develop- 
ment framework is available from SunSoft (Mountain 
view, CA). As will be appreciated by those skilled in the 

45 art, the object oriented principles of inheritance may be 
used to enable the object development framework to 
transparently provide the present invention to the dis- 
tributed object. 

As background, an object "class" is a template from 

50 which an object can be created. It is used to specify the 
behavior and attributes common to all objects of the 
class. The mechanism by which new classes are de- 
fined from existing classes is "inheritance." "Subclass- 
es" of a class inherit operations of their parent class. As 

55 js well known, "inheritance" is a mechanism by which 
reusability is facilitated. 

Fig. 2 illustrates one possible flow of the creation of 
an object in accordance with one embodiment of the 
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present invention. A data schema 170 is authored by 
the object developer. The data schema 1 70 defines and 
describes all the object variable structures and the na- 
tures thereof. The data schema 170 is then processed 
by a data compiler 172 to produce data object classes 
174. Thus the data object classes 1 74 describe the be- 
havior and attributes of the data for the object being de- 
veloped. In particular, the data object classes contain 
the values of data object pointers, the significance of 
which will be described in greater detail below. 

An implementation 176 is written by the object de- 
veloper which defines the behavior and attributes of the 
object being developed. The implementation 176 is 
compiled by an implementation compiler 178 to produce 
a compiled implementation 180. Note that data schema 
170, data object classes 174, implementation 176, and 
compiled implementation 180 are typically files written 
by the object developer or created by the compilers ac- 
cordingly. 

In particular, those of skill in the art will appreciate 
that during compilation statements referring to a data 
object are replaced by pointers to the data object. For 
example, during compilation a statement such as 'x.a 0 
where x is the servant and a is the data object member 
will be replaced by a statement such as "x.dop->a" 
where "dop" is the data object pointer whose value is 
found in the data object class. Thus, if the servant in- 
herits the data object the pointer will indirect data oper- 
ations (i.e., read and write operations) to the appropriate 
data object. 

The data object classes 174 and the compiled im- 
plementation 180 are then processed by another stage 
of the compiler 182 to produce an object constructor 
184. As will be appreciated by those skilled in the art, 
executing the object constructor 184 will produce an in- 
stance of the desired object. 

A representation of a servant object 1 50 in accord- 
ance with one embodiment of the present invention will 
be described now with respect to Fig. 3. Fig. 3 shows 
the servant object 150 of a distributed object class in- 
cluding transient data 152, a data object pointer 154, 
and a data object 158. In one embodiment, the servant 
inherits the data object. Thus, as will apparent to those 
of skill in the art, the value of data object pointer 154 is 
held in the data object class. This, of course, allows for 
the creation of multiple servants with an economy of ef- 
fort since all of the created servants inherit the value of 
the data object pointer from the same data object class. 

The servant object 150 is one instance of a distrib- 
uted object in accordance with one embodiment of the 
present invention. As will be appreciated by those skilled 
in the art of object oriented programming, when a new 
instance of a class is created, the memory for the in- 
stance variables is allocated. Fig. 3 diagramatically il- 
lustrates the memory allocation of servant object 150. 
Transient data 1 52 is the memory portion of the servant 
object 150 which contains state (e.g. variables) which 
the object needs to use only as transient data. By way 



of analogy, the transient data may be envisioned as a 
scratch pad area for use only by this instance of the serv- 
ant object 150. Data object 158 is the memory portion 
of the instance which the object developer intended for 
s use as persistent state. This region of memory is pointed 
to by data object pointer 1 54, which is inherited from the 
above-described data object classes. 

Initially, when the servant object 150 is created, an 
object constructor, such as object constructor 184, will 
10 create the servant object 150 with transient data 152 
and data object 1 58 in an initialized state (which may be 
random values left in the memory allocated to the data 
object or initialized to zero, etc.) Both the initialization 
function (executed during creation) and the activation 

*s function (executed during activation) must perform any 
required initialization. As described above, this requires 
the programmer to bear the burden of providing the nec- 
essary functions to implement persistence. 

However, according to preferred embodiments of 

20 the present invention, the original data object pointer 
1 54 which pointed to the data object 1 58 (as in Fig. 1 ) 
is replaced during either creation or activation with a per- 
sistent storage manager data object pointer 154 which 
points out to an area of memory holding a replica of the 

25 data object 158 called the persistent data object 162. 
The replica persistent data object 1 62 is mapped out of 
persistent storage such as a persistent database 164 
when the object is either created or activated. The 
stored form of the persistent data object 162 is gener- 

30 ated during creation and is maintained within the per- 
sistent database 164 until the object is deleted. Suitable 
methods for creating, activating, and deleting an object 
implementing transparent persistence in accordance 
with the present invention will be described in more de- 

35 tail below with reference to Figs. 7-10. 

In preferred embodiments the persistent data stor- 
age 164 is managed by a persistent storage manager. A 
suitable embodiment of the persistent storage manager 
is described in Hapner et. al.'s copending United States 

40 Patent Application Serial No. (Attor- 
ney Docket No. SUN1P036) entitled "METHODS AND 
APPARATUS FOR MANAGING A DATABASE IN A DIS- 
TRIBUTED OBJECT OPERATING ENVIRONMENT" 
which is incorporated herein by reference in its entirety. 

45 Distributed objects, as contemplated by the present 
invention, are implemented (by the ORB and/or the host 
computer) under computer processes. Computer proc- 
esses provide a well known and common framework un- 
der which computer systems implement different 

50 threads of execution. By way of analogy, a computer 
process can be thought of as a domain partitioned within 
a computer system. 

In actuality, a process typically includes address 
space (i.e. a portion of memory allocated to only the 

55 process), a set of file descriptors, a process identifica- 
tion number, and one or more threads of execution (of- 
ten referred to as threads). Multithreaded systems, such 
as contemplated in one embodiment of the present in- 
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vention, allow for multiple threads to run concurrently In 
a single process. For a more detailed description of 
threads, multi-threaded processes, and principles of 
concurrency, please see "Concurrency Within DOE Ob- 
ject Implementations" by Dr. Robert Hagmann, Version 
0.91 , May 27, 1 993, published by SunSoft and incorpo- 
rated herein by reference in its entirety. 

Fig. 4 illustrates an embodiment of the present in- 
vention including a mu It i -threaded process 100 in ac- 
cordance with one embodiment of the present invention. 
The process 100 may be implemented on a computer 
such as computer 30 and includes multiple threads such 
as thread 102, allocated memory 104 which may include 
both persistent and transient memory, file identifiers 
106, and at least one object such as object 108. The 
object 108 includes state 110 and code 112. The object 
108 is typically defined by the state 110 and the code 
112. Code 112 is essentially the operating instructions 
by which the object executes. State 110 is thus the re- 
maining portion which is not executable code. As will be 
appreciated, the state 110 is generally what the trans- 
parent persistence of the present invention is directed 
towards. In some embodiments of the present invention, 
a persistent storage manager maintains a single data- 
base accessible to a plurality of distributed objects re- 
siding in a plurality of processes. 

In a preferred embodiment of the present invention, 
distributed objects, computer processes, and clients of 
the distributed objects are resident on one or more com- 
puters linked together by a network. The network may 
take any suitable form. By way of example, a represent- 
ative network arrangement 1 0 is illustrated in Fig. 5. The 
network arrangement 10 includes a first computer 12 
which is coupled to a transmission line 14. The network 
10 further includes a server, router or the like 16 in ad- 
dition to other computers 18, 20, and 22 such that data 
and instructions can be passed among the networked 
computers. The design, construction and implementa- 
tion of computer networks will be familiar to those of skill 
in the art. 

A representative computer 30 suitable for use as 
computers 12, 18, 20, and/or 22 of Fig. 5 is illustrated 
schematically in Fig. 6. Computer 30 includes a central 
processing unit (CPU) 32 which is coupled bidirection- 
al^ with random access memory (RAM) 34 and unidi- 
rectionally with read only memory (ROM) 36. Typically, 
RAM 34 is used as a "scratch pad" memory and includes 
programming instructions and data, including distribut- 
ed objects and their associated code and state, for proc- 
esses currently operating on CPU 32. ROM 36 typically 
includes basic operating instructions, data and objects 
used by the computer to perform its functions. In addi- 
tion, a mass storage device 38, such as a hard disk, CD 
ROM, magneto-optical (floptical) drive, tape drive or the 
like, is coupled bidirectionally with CPU 32. Mass stor- 
age device 38 generally includes additional program- 
ming instructions, data and objects that typically are not 
in active use by the CPU, although the address space 



may be accessed by the CPU, e.g., for virtual memory 
or the like. Each of the above described computers op- 
tionally includes input/output sources 40 that typically 
include input media such as a keyboard, pointer devices 

5 {e.g., a mouse or stylus) and/or network connections. 
Additional mass storage devices (not shown) may also 
be connected to CPU 32 through a network connection. 
It will be appreciated by those skilled in the art that the 
above described hardware and software elements, as 

10 well as networking devices, are of standard design and 
construction, and will be well familiar to those skilled in 
the art. 

One method 200 for creating an object having trans- 
parent persistence in accordance with the present in- 
*5 vention is described now with reference to Fig. 7. The 
transparent persistence method 200 is for use in a va- 
riety of systems. By way of example, this method is well 
suited for use in distributed object operating environ- 
ments based on the CORBA specification. The method 
20 200 begins in a step 201 when an object creator is called 
to create the object. As will be appreciated by those 
skilled in the art, generally a factory class of an object 
is utilized to create the object. Typically upon object in- 
stallation, a single instance of the factory class is creat- 
ed and resides in a server process accessible by the 
appropriate clients. In some cases, clients which intend 
to request services may call this factory servant object 
to create an instance of the object for their own use: In 
other cases, the ORB may call the creator in response 
to a client requesting services. 

In any event, in a step 202 a servant object 150 is 
created. This is typically done by running an object con- 
structor as discussed previously. In step 202 a contigu- 
ous portion of memory is allocated for the servant object 
1 50 including memory for transient data 1 52, data object 
pointer 154, and data object 158. As discussed above, 
the value for the data object pointer 1 54 is inherited from 
the data object class. 

As allocated initially, the data object pointer 1 54 di- 
rects to the data object 158. Then, in a step 204, a per- 
sistent data object 162 is created. In preferred embodi- 
ments the persistent data object 162 (which is a replica 
of the data object programmed by the object developer) 
is mapped from storage in a persistent database 164 
where it is maintained by a persistent storage manager. 
In step 204, the persistent data object 162 is mapped 
into transient memory such as RAM 34. As will be ap- 
preciated by those skilled in the art, copying the persist- 
ent object data 162 into RAM 34 will enable quicker 
read/write operations then if maintained in persistent 
storage. 

In a next step 208, the object adapter object is ob- 
tained. This step includes registering the servant object 
150 with the ORB and receiving an object reference in 
return. Generating an object adapter object may be per- 
formed by well known methods. By way of example, the 
CORBA standard provides one suitable guideline for 
generating distributed objects such as required in step 
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208. Then, in a step 210, the object reference is stored 
in the object reference data maintained by the ORB on 
the servant object 150's host computer. In step 212, the 
initial data object pointer 154 is replaced with a persist- 
ent data pointer 154 which points out to the persistent 
data object 1 62 which was generated earlier in step 204. 
A more detailed description of one embodiment of step 
212 is described below with respect to Fig. 8. 

Next, in a step 214, the initialization procedures are 
performed. This may include such steps as setting the 
variable to initial values and reading in persistent data. 
The initialization procedure is authored (at least in part) 
by the object developer and may be unique to object 
creation. That is, different functions may be performed 
during creation initialization step 214 than during acti- 
vation. At this point the object is created, active, and able 
to accept requests for service, so in a step 21 6 the object 
reference is returned to the client which initiated the cre- 
ation method 200. 

One embodiment of a data pointer replacement 
step 212 of Fig. 7 is described in more detail now with 
reference to Fig. 8. By way of background, the embod- 
iment of Fig. 8 is suitable for use in state of the art object 
oriented programming languages such as C++ and 
SmallTalk. As these languages were not originally de- 
signed for distributed object operating environments or 
persistence strategies, the method of Fig. 8 provides 
one strategy for enabling the methods of the present in- 
vention in currently available programming frameworks. 
As will be appreciated by those skilled in the art, when 
other programming languages are used, the mecha- 
nisms of the data pointer replacement step 212 may be 
varied appropriately. 

The data pointer replacement method 208 of Fig. 8 
begins when a step determines the value of the data 
pointer 154. As discussed previously with reference to 
Fig. 2, certain characteristics of the distributed object 
are "inherited" from "parent" classes. In this case, the 
data pointer 154 is inherited from the data object class. 
As a result of the structure of current object oriented pro- 
gramming languages {e.g. C++ and SmallTalk) and the 
nature of inheritance, the address of the data pointer 
154 is "hidden", or unavailable to the distributed object. 
Furthermore, the address of the data pointer 154 is not 
constant during the life cycle of the distributed object. 
This is, in part, because during its different activation/ 
deactivation cycles a distributed object may be resident 
in different memory space (i.e. different addresses) dur- 
ing each activated phase. In general, the memory space 
allocated to the object upon activation is known by the 
ORB, but it doesnl know the specific location of the data 
pointer 154. 

However, as is well known, by performing the ap- 
propriate "widening" functions the value of the data 
pointer 154 can be obtained from the data object class. 
So once the value of the data pointer 154 is obtained in 
step 252, a step 254 will search the memory location of 
the distributed object to find the address space which 



contains the same value as found in step 252. The ad- 
dressing information found in step 254 enables a step 
256 to replace the value in the data pointer field 1 54 with 
a new data object pointer 154. In one embodiment, the 

s data object pointer 1 54 is provided by a persistent stor- 
age manager which maintains the data in persistent 
memory. For more details on the persistent storage 
manager, please see copending United States Patent 
Application Serial No. (Attorney Docket No. 

io SUN1P036/D422). In any event, once the data object 
pointer 154 has been replaced, the method of Fig. 8 is 
complete. 

It should be pointed out that in performing the 
search step 254 there is a very small risk that the value 
is obtained in the value determination step 252 is not 
unique within the memory space allocated to the distrib- 
uted object. Therefore in some embodiments a com- 
plete search of the memory space may be performed in 
step 254 in order to verify uniqueness. However, it is 
believed that the risk is so small that in most embodi- 
ments the extra verification step is unnecessary. As will 
be appreciated, obvious modifications of the method of 
Fig. 8 may be appropriate for use with different object 
oriented programming languages. For example, in 
some instances an object oriented programming lan- 
guage might provide a mechanism for directly obtaining 
the address of the data pointer 154. In this case the 
search of step 254 is unnecessary and the risk dis- 
cussed at the beginning of this paragraph is eliminated. 

A method 300 for activating an object in accordance 
with one aspect of the present invention will be de- 
scribed now with reference to Fig. 9. In a step 302, an 
invocation for the object is received. The invocation may 
be received by the server process under which the ob- 
ject is intended to reside. Then, in a step 304, the server 
process determines if the object is active. If the object 
is already active, then the persistent data object 162 is 
already in place and the data object pointer 154 has 
been swapped as described above. Therefore the steps 
of activation relevant to the present invention have al- 
ready been performed and the activation method 300 is 
complete. 

If the object is inactive, then, in step 306, the con- 
structor is called to create a servant object 1 50 . In step 
306 a contiguous portion of memory is allocated for the 
servant object 150 including memory for transient data 
152, data object pointer 154, and data object 158. As 
allocated initially, the data object pointer 154 directs to 
the data object 158. Note that step 306 of Fig. 9 is anal- 
ogous to step 202 of Fig. 7. Then, in a step 308, a per- 
sistent data object 1 62 is retrieved from storage in a per- 
sistent database 164 and mapped into transient mem- 
ory such as RAM 34. As will be appreciated by those 
skilled in the art, copying the persistent object data 162 
into RAM 34 will enable quicker read/write operations 
then if maintained in persistent storage. Note that this 
step is similar to the create data object step 204 of Fig. 7. 
However in the retrieve step 308, the data object 
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replica has already been created so It can be read di- 
rectly from the persistent database 164. When the data 
object 162 has been mapped into memory its address 
is known, so therefore in a step 310 the original data 
object pointer 1 54 is replaced with a data object pointer s 
which points to the persistent data object 162 using the 
method described above. After the pointer replacement 
step 310, in step 312 any activation initialization steps 
are performed. In some embodiments an activation 
hook is programmed by the object developer and de- fo 
fines all the necessary functions which must be per- 
formed upon activation. Note that the activation hook is 
not necessarily identical to the initialization performed 
in the initialization step 21 4 of object creation 200 in Fig. 
7. 15 

One method 350 for deleting an object in accord- 
ance with one embodiment of the present invention will 
be described now with reference to Fig. 1 0. In a first step 
352, a client calls the object to invoke a "destroy" oper- 
ation. By way of explanation, it is a sound programming 20 
strategy to have object deletion (even if initiated exter- 
nally) be a self-performed act. This insures an orderly 
shutdown and deletion as defined by the object devel- 
oper. Therefore the object will have an operation such 
as "destroy" available to clients through its interface (As 25 
opposed to an entity independent of the object deleting 
the object). Objects may be deleted for a variety of rea- 
sons such as non-activity or replacement. One suitable 
method for systematically deleting objects when they (or 
the process they reside in) become inactive is described so 
in Snyder et. al.'s copending United States Patent Ap- 
plication Serial No. (Attorney Docket No. 
SUN1P035/P769) which is incorporated herein by ref- 
erence in its entirety. 

In any event, once the object receives a request to 35 
self-destroy, in a step 354 it performs its internal delete 
operation. This may include systematic deactivation 
steps such as completing all pending service requests 
while blocking out any new requests and broadcasting 
a final message indicating that deletion is completed. 40 
One suitable method for deactivating an object is de- 
scribed in Yeturu Aahlad's copending United States Pat- 
ent Application Serial No. (Attorney Docket No. 
SUN1P026/P718) entitled "METHODS AND APPARA- 
TUS FOR MANAGING DEACTIVATION AND SHUT- 45 
DOWN OF A SERVER", which is incorporated herein 
by reference in its entirety. In a next step 356, the per- 
sistent data associated with the object is deleted. This 
may be performed by the object itself during the destroy 
operation, or may be done by the persistent storage so 
manager after the object has performed the destroy op- 
eration, or may be performed by other computer entities 
such as the operating system. In any event, once the 
object and its persistent data has been deleted the 
method 350 of Fig. 10 is complete. ss 

Although only a few embodiments of the present in- 
vention have been described, it should be understood 
that the present invention may be embodied in many 



other specific forms without departing from the spirit or 
scope of the invention. For example, the embodiment of 
Fig. 2 simply provides one sample object development 
procedure. However, as will be appreciated by those 
skilled in the art, many other object development proce- 
dure may be used to implement the methods and appa- 
ratus of the present invention 

In the embodiment described with reference to Fig. 
9, the transparent persistence method 300 is initiated 
by a client calling ttie distributed object. However, other 
suitable events may initiate the method of Fig. 9. For 
example, a distributed object may be self-activating. 
Furthermore, there may be other determination steps 
which occur before implementing the replace data point- 
er step 310. By way of example, there may be activation 
circumstances under which the object data of a previous 
activation should be ignored. In this case, a different 
pointer may be returned to the distributed object, pro- 
viding it with a "new" location to store its persistent data. 
Therefore, the present examples are to be considered 
as illustrative and not restrictive, and the invention is not 
to be limited to the details given herein, but may be mod- 
ified within the scope of the appended claims. 



Claims 

1. A computer-implemented method for providing a 
distributed object having transparent persistent da- 
ta support for use on a distributed object system, 
the method comprising the steps of: 

a) providing a servant object having an associ- 
ated data object in which transient data can be 
stored and a data object pointer that indirects 
to the associated data object, wherein the serv- 
ant object inherits the data object from a data 
object class; 

b) providing a persistent data storage mecha- 
nism having a persistent data object in which 
persistent data is stored and a persistent data 
pointer that indirects to the persistent data ob- 
ject; 

c) determining the value of the data object 
pointer; and 

d) locating the data object pointer within the 
servant object and replacing the data object 
pointer with the persistent data pointer to pro- 
duce thereby a distributed object having trans- 
parent persistent data support. 

2. The computer-implemented method of claim 1, 
wherein the persistent data storage mechanism 
comprises a persistent database which is coupled 
to the persistent data object. 

3. The computer-implemented method of claim 2, 
wherein the persistent database mechanism in- 
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eludes a persistent storage manager. 

4. The computer-implemented method of claim 1, 
wherein said step of determining comprises the 
step of performing a widening function on the serv- 
ant object to determine thereby the data object 
pointer in the data object class. 

5. The computer-implemented method of claim 4, 
wherein the step of locating comprises searching 
the memory location of the servant object to obtain 
the location of an address space containing a value 
identical to the data object pointer. 

6. The computer-implemented method of claim 5, 
wherein said step of locating further comprises the 
step of searching the entire memory space of the 
servant object to verify the uniqueness of the ad- 
dress of the data object pointer. 

7. The computer-implemented method of claim 1, 
wherein the distributed object is located in the mem- 
ory of a computer on a distributed object system, 
which distributed object system includes a plurality 
of networked computers having memories in which 
distributed objects and clients are located and 
which distributed objects communicate using an ob- 
ject request broker mechanism and an object 
adapter mechanism. 

8. The computer-implemented method of claim 7, 
wherein the steps a)-d) are performed in response 
to an invocation of the servant object by a client on 
the distributed object system. 

9. The computer-implemented method of claim 7, 
wherein the steps a)-d) are performed during the 
creation and installation of the servant object on the 
distributed object system. 

10. A distributed object having transparent persistent 
data support formed by the computer-implemented 
method of claim 1 . 

1 1 . A computer system for creating a distributed object 
having transparent, persistent data support, com- 
prising: 

a) a data compiler to compile data schema into 
a data object classe; 

b) an implementation compiler to compile im- 
plementation files into compiled implementa- 
tions; 

c) a final stage compiler to create a servant ob- 
ject constructor capable of creating a servant 
object, the servant object including a transient 



data space, a data object pointer and a data 
object, wherein the servant object inherits the 
data object pointer from the data object class; 

5 d) a persistent data storage mechan ism that in- 

cludes a persistent database a persistent data 
object that is an image of the persistent data- 
base; and 

io e) a transparent persistence mechanism that 

includes a locator to find the value of the data 
object and the address space of the data object, 
and a replacement mechanism to swap the val- 
ue of the data object in the address space with 

*5 a pointer to the persistent data object. 

12. The computer system of claim 11 , wherein the per- 
sistent data storage mechanism includes a persist- 
ent storage manager that provides the persistent 

20 data object pointer. 

13. The computer system of claim 1 1 , wherein the tran- 
sient data space, the data object pointer and the da- 
ta object occupy contiguous areas of memory in a 

25 computer. 

14. The computer system of claim 1 3, wherein the lo- 
cator includes a widening mechanism to determine 
the value of the data object pointer and a searching 

30 mechanism to search the memory space of the 
servant object for the memory address of the data 
object pointer. 

15. The computer system of claim 11 , wherein the dis- 
ss tributed object is located in the memory of a com- 
puter on a distributed object system, which distrib- 
uted object system includes a plurality of networked 
computers having memories in which distributed 
objects and clients are located and which distribut- 
ee? ed objects communicate using an object request 

broker mechanism and an object adapter mecha- 
nism. 

16. The computer system of claim 15, wherein the 
45 transparent persistence mechanism is activated in 

response to an invocation of the servant. 

17. The computer system of claim 15, wherein the 
transparent persistence mechanism is activated in 

50 response to the creation of the servant. 

18. A distributed object having transparent persistent 
data support formed by the computer system of 
claim 12. 

55 

19. A distributed object suitable for use on a distributed 
object system, comprising a transient data space 
for storing transient data, a data object and a per- 



15. 



35 



40 



11 



21 



EP 0 735 465 A1 



sistent data pointer that indirects the reading and 
writing of persistent data from the data object to a 
persistent data object, which persistent data object 
is an image of a persistent database. 
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